Media file synchronization

ABSTRACT

The description generally relates to a system designed to synchronize the rendering of a media file between a master device and a sister device. The system is designed so that a media file is simultaneously rendered on a master device and a sister device beginning from identical temporal starting points.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation application under 35 U.S.C. § 120 ofU.S. patent application Ser. No. 14/563,709, filed on Dec. 8, 2014,which is a continuation application under 35 U.S.C. § 120 of U.S. patentapplication Ser. No. 12/367,287, filed on Feb. 6, 2009, now U.S. Pat.No. 9,077,784, issued on Jul. 7, 2015. The disclosures of U.S. patentapplication Ser. No. 14/563,709 and U.S. patent application Ser. No.12/367,287 are hereby incorporated by reference in their entireties.

BACKGROUND

It is well known that media files may be transferred from one device toanother via various means. Currently, a media file is transferred fromone device to another, and subsequently the user selects a point withinthe media file to be the starting point from which the media file willbe rendered.

With users of media files desiring to experience the same media contenton multiple devices, it is more imperative than ever to create systemsthat allow the synchronization of media files across various devices andwhich further allow the acquisition of media files which are resident onone device but not others.

Unfortunately, an adequate solution that addresses these issues haseluded those skilled in the art, until now.

SUMMARY

The present disclosure describes solutions that enable thesynchronization of one or more media files between a master device and asister device, so that the media file is simultaneously rendered on bothdevices beginning from identical temporal starting points. The use of acomputer network is employed with middleware to condition the media filein a manner which makes the media file compatible with the sisterdevice. The data transactions between the middleware and the sisterdevice may also be handled to search for the appropriate media file,acquire it, and transmit it to the sister device.

The foregoing is a summary that thus contains, by necessity,simplifications, generalization, and omissions of detail; consequently,those skilled in the art will appreciate that the summary isillustrative only and is not intended to be in any way limiting. Otheraspects, features, and advantages of the devices and/or processes and/orother subject matter described herein will become apparent in theteachings set forth herein. The summary is provided to introduce aselection of concepts in a simplified form that are further describedbelow in the Detailed Description. This summary is not intended toidentify key features or essential features of the claimed subjectmatter, nor is it intended to be used as an aid in determining the scopeof the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other features of the present disclosure will becomemore fully apparent from the following description and appended claims,taken in conjunction with the accompanying drawings. Understanding thatthese drawings depict only several embodiments in accordance with thedisclosure and are, therefore, not to be considered limiting of itsscope, the disclosure will be described with additional specificity anddetail through the use of the accompanying drawings.

FIG. 1 is a functional block diagram of a computing environmentimplementing one embodiment of a system for media synchronization.

FIG. 2 is a functional block diagram illustrating in greater detail oneimplementation of the data file introduced in conjunction with FIG. 1.

FIG. 3 is a functional block diagram illustrating in greater detail themaster device introduced in conjunction with FIG. 1.

FIG. 4 is a functional block diagram illustrating in greater detail thesister device introduced in conjunction with FIG. 1.

FIG. 5 is a functional block diagram illustrating in greater detail themiddleware server and the network introduced in conjunction with FIG. 1.

FIG. 6 is an operational flow diagram generally illustrating a processfor transmitting a data file between a master device and a sister devicein such a manner as to ensure synchronization of media.

FIG. 7A is another operational flow diagram generally illustrating aprocess for receiving a data file at a sister device in such a manner asto ensure synchronization of media.

FIG. 7B is yet another operational flow diagram generally illustrating aprocess for receiving a data file at a sister device in such a manner asto ensure synchronization of media.

FIG. 7C is still yet another operational flow diagram generallyillustrating a process for receiving a data file at a sister device insuch a manner as to ensure synchronization of media.

FIG. 8 illustrates by way of a schematic flow diagram another embodimentof the present system and method for media synchronization.

FIG. 9 is a diagram generally illustrating a computer product configuredto perform processing for the media synchronization system shown in FIG.1.

FIG. 10 is a functional block diagram generally illustrating an examplecomputing device that is arranged for media synchronization inaccordance with the present disclosure.

It should be noted that the embodiments illustrated in these figures arerepresentative only, and are not exclusive of all the embodiments thatmay implement a media synchronization system.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

In the following detailed description, reference is made to theaccompanying drawings, which form a part hereof. In the drawings,similar symbols typically identify similar components, unless contextdictates otherwise. The illustrative embodiments described in thedetailed description, drawings, and claims are not meant to be limiting.Other embodiments may be utilized, and other changes may be made,without departing from the spirit or scope of the subject matterpresented here. It will be readily understood that the aspects of thepresent disclosure, as generally described herein, and illustrated inthe Figures, can be arranged, substituted, combined, and designed in awide variety of different configurations, all of which are explicitlycontemplated and make part of this disclosure.

This disclosure is drawn, inter alia, to methods, apparatus, computerprograms and systems related to a media synchronization system. Certainpreferred embodiments of one such system are illustrated in the figuresand described below. Many other embodiments are also possible, however,time and space limitations prevent including an exhaustive list of thoseembodiments in one document. Accordingly, other embodiments within thescope of the claims will become apparent to those skilled in the artfrom the teachings of this patent.

FIG. 1 is a functional block diagram of a computing environmentimplementing one embodiment of a system for media synchronization. Asshown, master device 101 transmits data file 102 to sister device 105,through a “middleware” server 104 connected to a network 103. Brieflydescribed, the master device 101 may be any device, either mobile ornon-mobile, capable of rendering media files such as MP3 files, WAVfiles, MPEG files, and the like. Several examples of master device 101include a wireless handheld device, a digital video recorder, a homemedia server, or any other mobile or non-mobile device capable ofrendering media files.

Sister device 105 may be any device, either mobile or non-mobile,capable of rendering media files such as MP3 files, WAV files, MPEGfiles, and the like. Several examples of sister device 105 include ahome media server, a digital video server, a video receiver, a computer,a cellular telephone, a smart telephone, a personal digital assistant(PDA), a digital music player, a digital video player, a portable videoplayer, a wireless handheld device, a mobile communication device, avehicle navigation system, a vehicle media system, a laptop personalcomputer (PC), a notebook PC, a mobile computing device, or any othermobile or non-mobile device capable of rendering media files.

The data file 102 is described in greater detail below in conjunctionwith FIG. 2. FIG. 2 is a functional block diagram illustrating ingreater detail one implementation of the data file introduced inconjunction with FIG. 1. Briefly described, the data file 102 includes aheader 234. Header 234 includes a media code 235 which uniquelyidentifies media file 237 from other media files, such as by title ordescription. Media file 237 may be an MP3 file, a WAV file, an MPEGfile, or any other video file, audio file, or audiovisual file which,when rendered by a mobile or non-mobile device, allows the user to viewvideo content, listen to audio content, or view and listen toaudiovisual content. In the illustrated embodiment of FIG. 2, the mediafile 237 is included in data file 102. In other embodiments, media file237 may be resident on sister device 105 or available for acquisitionvia network 103.

Header 234 also includes a time code 236 which corresponds to a temporalstarting point within media file 237. For instance, time code 236 mayidentify the temporal starting point “1:05” within media file 237,indicating that upon receipt of data file 102, media file 237 is to berendered beginning from the point which occurs exactly one hour and fiveminutes from the beginning of media file 237. In another embodiment,time code 236 may be modified continuously until receipt of data file102 by a sister device. For instance, time code 236 may identify thetemporal starting point “1:05+elapsed time”, indicating that uponreceipt of data file 102, media file 237 is to be rendered beginningfrom the point which occurs exactly one hour and five minutes from thebeginning of media file 237 plus the elapsed time between transmissionof data file 102 by master device 101 and receipt of data file 102 bysister device 105. In this instance, if exactly one minute elapsedbetween transmission and receipt of data file 102, the temporal startingpoint would be the point which occurs exactly one hour and six minutesfrom the beginning of media file 237.

FIG. 3 is a functional block diagram illustrating in greater detail themaster device introduced in conjunction with FIG. 1. As illustrated,master device 101 includes a media player 309, which may be RealPlayer®,Windows Media® Player, a digital video player, a digital audio player,or any other application or device capable of rendering audio content,media content, or audiovisual content. Media player 309 is capable ofplaying media file(s) 312, which may be MP3 file(s) 313, WAV file(s)314, MPEG file(s) 315, or other media file(s) 316. Media player 309 mayrender a media file 312 using audio hardware 310, video hardware 311, orsome combination of both. Alternatively, the media player 309 couldrender the media file 312 using software, such as streaming it usingcommunications module 306.

Master Media Synchronization Application (MMSA) 307 is a softwareapplication which may be instructed to search for the presence of asister device such as sister device 105 illustrated in FIG. 1. Upondiscovering that a sister device is present, MMSA 307 may be instructedto cause the media file 312 to be synchronously rendered on masterdevice 301 and sister device 105. MMSA 307 interacts with media player309 in a manner that allows identification of media file 312 which isbeing rendered by media player 309. MMSA 307 generates a media code 235(e.g., see FIG. 2) which identifies media file 312.

MMSA 307 also determines the precise amount of time which has elapsedfrom the beginning of media file 312 to the point in media file 312which is currently being rendered by media player 309, and converts thattime into a time code 236 (e.g., see FIG. 2). For instance, if mediaplayer 309 is currently playing a scene from media file 312 which occursexactly one hour and five minutes from the beginning of media file 312,the time code 236 may be “1:05”. Alternatively, the user of masterdevice 101 may use controller 308 to set time code 236 to correspond toany temporal point within media file 312. After MMSA 307 generates themedia code 235 and the time code 236, MMSA 307 creates a data file 102which includes media code 235 and time code 236. MMSA 307 alsodetermines whether media file 312 contains permissions enabling the userto view and/or listen to media file 312 on a sister device. If mediafile 312 contains the necessary permissions, MMSA 307 includes mediafile 312 in data file 102. If media file 312 does not contain thenecessary permissions, MMSA 307 omits media file 312 from data file 102.

After MMSA 307 generates data file 102, MMSA 307 transmits data file 102to the communications module 306 resident on the master device 101. Thecommunications module 306 is a component configured to facilitatedigital or analog communications between the master device 101 and anyother device, such as over a network, using wireless communications, orthe like. In one specific implementation, communications module 306 maybe implemented as an ethernet or Bluetooth® driver stack, although manyother examples will become apparent to those skilled in the art.Communications module 306 transmits the data file 102 to sister device105 through middleware server 104. In another embodiment, master device101 may transmit data file 102 directly to sister device 105.

FIG. 4 is a functional block diagram illustrating in greater detail thesister device introduced in conjunction with FIG. 1. Sister device 105includes a sister device communications module 417, configured to beinteroperative with communications module 306, which receives data file102 and transmits data file 102 to sister media synchronizationapplication (SMSA) 418. Sister device 105 further includes local datastorage 424, which includes media store 425 and header store 426. SMSA418 stores media file 237 (e.g., see FIG. 2) in media store 425, andalso stores header 234 (e.g., see FIG. 2) in header store 426. Aspreviously described with respect to FIG. 2, header 234 includes timecode 236. SMSA 418 reads time code 236 and instructs sister media player420 to render media file 237 from the temporal starting point identifiedby time code 236.

Subsequently, sister media player 420 renders media file 237 using audiohardware 310, video hardware 311, or both, beginning at the temporalstarting point identified by time code 236. Alternatively, the sistermedia player 420 could render the media file 237 using software, such asstreaming it using sister communications module 417. The user of sistermedia player 420 may modify the temporal starting point using sistercontroller 423. Sister media player 420 may be RealPlayer®, WindowsMedia® Player, a digital video player, a digital audio player, or anyother application or device capable of rendering audio content, mediacontent, or audiovisual content. A user application programminginterface (API 419) may link SMSA 418 with sister media player 420. SMSA418 and sister media player 420 may also share resources via a dynamiclink library (DLL) 427. SMSA 418 and MMSA 307 may have the capability ofbeing remotely updated by authorized persons.

If data file 102 does not include media file 237, then SMSA 418 readsmedia code 235 in data file 102 and searches media store 425 for mediafile 237, which is identified by media code 235. If SMSA 418 locatesmedia file 237 in media store 425, then SMSA 418 instructs sister mediaplayer 420 to render media file 237 from the temporal starting pointidentified by time code 236. If SMSA 418 does not locate media file 237in media store 425, then SMSA 418 transmits a request to middlewareserver 104 to search for media file 237. SMSA 418 may also transmit arequest to middleware server 104 to search for media file 237 in theevent that data file 102 contains a media file which is corrupted,violates a third party's intellectual property rights, or which isotherwise impossible to render or not permitted to be rendered on sisterdevice 105.

FIG. 5 is a functional block diagram illustrating in greater detail themiddleware server and the network introduced in conjunction with FIG. 1.As illustrated, middleware server 104 includes a search engine 531, apayment module 532, and a logic 533. The middleware server 104 isconnected to network 103 which is associated with disparate storagedevices (e.g., data store A 527, data store B 528, data store C 529, anddata store D 530), on which media files and other information can bestored.

Upon receipt of a request from SMSA 418 to search for media file 237,search engine 531 searches various data stores connected over network103 to determine whether media file 237 is available on any of thevarious storage devices (e.g., data store A-D (527-530)) coupled tonetwork 103. When search engine 531 locates media file 237 on network103, search engine 531 instructs payment module 532 to arrange forpayment for media file 237. Payment module 532 arranges for payment formedia file 237 and, after the payment transaction is complete,authorizes logic 533 to acquire media file 237. Logic 533 causes mediafile 237 to be retrieved over network 103 from the appropriate storagedevice on which media file 237 is found to the middleware server 104.The logic 533 may then configure media file 237 to make it capable ofbeing rendered on sister device 105. For example, logic 533 may convertmedia file 237 to the proper format, file size, encryption, digitalrights management (DRM) and other specifications so as to enable mediafile 237 to be rendered on sister device 105. This configuration processmay take place in a buffer or other data storage facility (e.g., localdata store 537) in the middleware server 104. When the configurationprocess is complete, middleware server 104 transmits media file 237 tosister device 105.

FIG. 6 is an operational flow diagram generally illustrating a processfor transmitting a data file between a master device and a sister devicein such a manner as to ensure synchronization of media. The processincludes operation 601, at which the master device senses the sisterdevice is present. At operation 602, the master device creates a datafile including a header, which header includes a media code and a timecode. At operation 604, if the master device user has the permissionsnecessary to allow the media file identified by the media code to berendered on both the master device and the sister device, as in thisparticular example, the data file also includes the media file(operation 608).

At operation 603, the master device transmits the data file to themiddleware server. If the media file is already configured in a formwhich enables it to be rendered on the sister device, the middlewareserver may transmit the data file directly to the sister device withoutfurther modification. In this particular embodiment, at operation 604,the middleware server configures the media file for rendering on thesister device. At operation 605, the middleware server transmits thedata file to the sister device.

FIG. 7A is another operational flow diagram generally illustrating aprocess for receiving a data file at a sister device in such a manner asto provide synchronization of media. The process includes operation 701,at which the sister device receives a data file including a header,which header includes a media code and a time code. At operation 702,the sister media synchronization application (SMSA) stores the header inthe header store which is included on the sister device. In thisparticular example, the data file includes the media file which isidentified by the media code. At operation 703, the SMSA searches themedia store on the sister device to determine whether the media fileidentified by the media code is present. In this particular example, themedia file is present on the media store, and the SMSA locates the mediafile in the media store at operation 704. At operation 705, the SMSAretrieves the header from the header store on the sister device. Atoperation 706, the SMSA instructs the sister media player to render themedia file beginning from the temporal starting point identified by thetime code in the header. At operation 707 the sister media playerrenders the media file.

FIGS. 7B and 7C are other operational flow diagrams generallyillustrating an alternative process for receiving a data file at asister device in such a manner as to provide synchronization of media.The process includes operation 711, at which the sister device receivesa data file including a header, which header includes a media code and atime code. At operation 712, the sister media synchronizationapplication (SMSA) stores the header in the header store which isincluded on the sister device. In this particular example, the data filedoes not include the media file which is identified by the media code.At operation 713, the SMSA searches the media store on the sister deviceto determine whether the media file identified by the media code ispresent. In this particular embodiment, the media file is not present onthe media store.

At operation 714, the SMSA transmits a request to the middleware serverto obtain the media file. Subsequently, at operation 715, the searchengine resident on the middleware server locates the media file on thenetwork to which the middleware server is connected. At operation 716,the payment module resident on the middleware server arranges forpayment for the media file. At operation 717, payment module instructsthe logic resident on the middleware server to acquire the media file.At operation 718, the logic receives the media file and stores the mediafile on the middleware server. In this particular embodiment, when themedia file reaches the middleware server, the media file is notconfigured in a manner which allows it to be rendered on the sisterdevice. In one example, the media file may be configured in the mannerdescribed above with respect to FIG. 5. At operation 719, the logicresident on the middleware server configures the media file in a mannerwhich allows it to be rendered on the sister device. In one example,configuring the media file is accomplished by converting the media fileto a proper format, a file size, encryption, digital rights management(DRM), and other specifications, so as to enable the media file to berendered on the sister device. At operation 720, the middleware servertransmits the media file to the sister device.

At operation 721, the SMSA stores the media file in the media storelocated on the sister device. At operation 722, the SMSA retrieves theheader from the header store on the sister device. At operation 723, theSMSA instructs the sister media player to render the media filebeginning from the temporal starting point identified by the time codein the header. At operation 724, the sister media player renders themedia file.

FIG. 8 illustrates by way of a schematic flow diagram another embodimentof the present system and method for media synchronization. In operation801, a data file is received by a sister device. In operation 802, thedata file is stored by the sister device, which stores the header in theheader store and, if the media file is present, also stores the mediafile in the media store. Operation 803 is a decision block thatdetermines if the media file is received by the sister mediasynchronization application (SMSA). If the media file is not present,the sister media synchronization application (SMSA) requests themiddleware server obtain the media file as illustrated by operation 804.If the media file is present, the SMSA retrieves the header from theheader store as illustrated by operation 813.

At operation 805, the search engine located on the middleware serversearches the data stores on the network to which the middleware serveris coupled, in an attempt to locate the media file. Operation 806 is adecision block that determines if the media file is available. If themedia file is not available at operation 806, then a message is sent tothe sister device to inform the sister device user that the media fileis unavailable at operation 807, where the process ends. If the mediafile is available at operation 806, then the payment module on themiddleware server arranges for payment for the media file at operation808. At operation 809, the media file is retrieved by the middlewareserver. At operation 810, the logic on the middleware server configuresthe media file in a manner that makes the media file capable of beingrendered on the sister device. At operation 811, the media file istransmitted from the middleware server to the sister device. Atoperation 812, the media file is stored by the sister device.

Operation 814 is a decision block that determines if a sister controlleris used to override the original time code obtained from the header. Ifthe user of the sister device uses the sister controller to override theoriginal time code in the header at operation 814, then the sister mediaplayer is requested to render the media file beginning at the temporalstarting point identified by the sister controller at operation 816. Thesister media player then renders the media file at operation 817 and theprocess ends. If there is no sister controller override at operation814, then the sister media player is requested to render the media filebeginning at the temporal starting point identified by the time code inthe header as illustrated by operation 815. The sister media player thenrenders the media file at operation 817 and the process ends.

FIG. 9 is a diagram generally illustrating a computer product configuredto perform processing for the media synchronization system shown inFIG. 1. The computer program product 900 may take one of several forms,such as a computer-readable medium 902 having computer-executableinstructions 904, a recordable medium 906, a communications medium 908,or the like. When the computer-executable instructions 904 are executed,a method is performed. The instructions 904 include, among others,receiving a data file at a sister device, the data file including amedia code and a time code, the media code identifying a media file, andthe time code identifying a temporal starting point within the mediafile; storing the data file; and rendering the media file from thetemporal starting point.

FIG. 10 is a functional block diagram generally illustrating an examplecomputing device 1000 that is arranged for media synchronization inaccordance with the present disclosure. In a very basic configuration1001, computing device 1000 typically includes one or more processors1010 and system memory 1020. A memory bus 1030 can be used forcommunicating between the processor 1010 and the system memory 1020.

Depending on the desired configuration, processor 1010 can be of anytype including but not limited to a microprocessor (μ13), amicrocontroller (μC), a digital signal processor (DSP), or anycombination thereof. Processor 1010 can include one or more levels ofcaching, such as a level one cache 1011 and a level two cache 1012, aprocessor core 1013, and registers 1014. The processor core 1013 caninclude an arithmetic logic unit (ALU), a floating point unit (FPU), adigital signal processing core (DSP core), or any combination thereof. Amemory controller 1015 can also be used with the processor 1010, or insome implementations, the memory controller 1015 can be an internal partof the processor 1010.

Depending on the desired configuration, the system memory 1020 can be ofany type including but not limited to volatile memory (such as RAM),non-volatile memory (such as ROM, flash memory, etc.) or any combinationthereof. System memory 1020 typically includes an operating system 1021,one or more applications 1022, and program data 1024. Application 1022includes a media synchronization algorithm 1023 that is configured tosupport the synchronizing of media file play between two or moredevices. Program Data 1024 includes media file 1025 that is useful formedia synchronization as has been further described above (e.g., pleaselist some examples). In some embodiments, application 1022 can bearranged to operate with program data 1024 and an operating system 1021such that media synchronization is facilitated between a master deviceand one or more sister devices. This described basic configuration isillustrated in FIG. 10 by those components within line 1001.

Computing device 1000 can have additional features or functionality, andadditional interfaces to facilitate communications between the basicconfiguration 1001 and any required devices and interfaces. For example,a bus/interface controller 1040 can be used to facilitate communicationsbetween the basic configuration 1001 and one or more data storagedevices 1050 via a storage interface bus 1041. The data storage devices1050 can be removable storage devices 1051, non-removable storagedevices 1052, or a combination thereof. Examples of removable storageand non-removable storage devices include magnetic disk devices such asflexible disk drives and hard-disk drives (HDD), optical disk drivessuch as compact disk (CD) drives or digital versatile disk (DVD) drives,solid state drives (SSD), ad tape drives to name a few. Example computerstorage media can include volatile and nonvolatile, removable andnon-removable media implemented in any method or technology for storageof information, such as computer readable instructions, data structures,program modules, or other data.

System memory 1020, removable storage 1051 and non-removable storage1052 are all examples of computer storage media. Computer storage mediaincludes, but is not limited to, RAM, ROM, EEPROM, flash memory or othermemory technology, CD-ROM, digital versatile disks (DVD) or otheroptical storage, magnetic cassettes, magnetic tape, magnetic diskstorage or other magnetic storage devices, or any other medium which canbe used to store the desired information and which can be accessed bycomputing device 1000. Any such computer storage media can be part ofdevice 1000.

Computing device 1000 can also include an interface bus 1042 forfacilitating communication from various interface devices (e.g., outputinterfaces, peripheral interfaces, and communication interfaces) to thebasic configuration 1001 via the bus/interface controller 1040. Exampleoutput devices 1060 include a graphics processing unit 1061 and an audioprocessing unit 1062, which can be configured to communicate to variousexternal devices such as a display or speakers via one or more AN ports1063. Example peripheral interfaces 1070 include a serial interfacecontroller 1071 or a parallel interface controller 1072, which can beconfigured to communicate with external devices such as input devices(e.g., keyboard, mouse, pen, voice input device, touch input device,etc.) or other peripheral devices (e.g., printer, scanner, etc.) via oneor more I/O ports 1073. An example communication device 1080 includes anetwork controller 1081, which can be arranged to facilitatecommunications with one or more other computing devices 1090 over anetwork communication via one or more communication ports 1082. Thecommunication connection is one example of a communication media.Communication media may typically be embodied by computer readableinstructions, data structures, program modules, or other data in amodulated data signal, such as a carrier wave or other transportmechanism, and includes any information delivery media. A “modulateddata signal” can be a signal that has one or more of its characteristicsset or changed in such a manner as to encode information in the signal.By way of example, and not limitation, communication media can includewired media such as a wired network or direct-wired connection, andwireless media such as acoustic, radio frequency (RF), infrared (IR) andother wireless media. The term computer readable media as used hereincan include both storage media and communication media.

Computing device 1000 can be implemented as a portion of a small-formfactor portable (or mobile) electronic device such as a cell phone, apersonal data assistant (PDA), a personal media player device, awireless web-watch device, a personal headset device, an applicationspecific device, or a hybrid device that include any of the abovefunctions. Computing device 1000 can also be implemented as a personalcomputer including both laptop computer and non-laptop computerconfigurations.

As will be appreciated by those persons skilled in the art, the systemand method described herein affords distinct advantages not previouslyavailable to users of media files. The present system and method allowsusers to synchronize media files between a master device and a sisterdevice exactly to a preferred point of usage, so that users of bothdevices are experiencing the same media file in the same temporalsequence. For instance, when both users are watching a movie, at alltimes the frame which is rendered on the master device will be identicalto the frame which is rendered on the sister device. Further, thepresent system and method allows the user of a sister device to acquireand configure media files which were not originally present on thesister device, enabling the user of the sister device to experience thesame media file which is being rendered on the master device, beginningat the same temporal starting point.

In another aspect, in this embodiment of the present system and methodfor media synchronization, each master device and each sister device mayrun a specialized media synchronization application that enables as muchportability to other devices as the device technology allows and is madeavailable by willing manufacturers and service providers. The ability toinstall a unified media player with the media synchronizationapplication will speed adoption of the system as there will be fewercompatibility and updating issues to consider. Device portabilityoptions may be presented in an application menu for the SMSA. The mediasynchronization application for each master device and each sisterdevice may be updated easily via application updates pushed from acentral server system.

Additional advantages and modifications will readily occur to thoseskilled in the art. Therefore, the invention in its broader aspects isnot limited to the specific details and representative embodiments shownand described herein. Accordingly, various modifications may be madewithout departing from the spirit or scope of the general inventiveconcept as defined by the appended claims and their equivalents.

There is little distinction left between hardware and softwareimplementations of aspects of systems; the use of hardware or softwareis generally (but not always, in that in certain contexts the choicebetween hardware and software can become significant) a design choicerepresenting cost vs. efficiency tradeoffs. There are various vehiclesby which processes and/or systems and/or other technologies describedherein can be effected (e.g., hardware, software, and/or firmware), andthat the preferred vehicle will vary with the context in which theprocesses and/or systems and/or other technologies are deployed. Forexample, if an implementer determines that speed and accuracy areparamount, the implementer may opt for a mainly hardware and/or firmwarevehicle; if flexibility is paramount, the implementer may opt for amainly software implementation; or, yet again alternatively, theimplementer may opt for some combination of hardware, software, and/orfirmware.

The foregoing detailed description has set forth various embodiments ofthe devices and/or processes via the use of block diagrams, flowcharts,and/or examples. Insofar as such block diagrams, flowcharts, and/orexamples contain one or more functions and/or operations, it will beunderstood by those within the art that each function and/or operationwithin such block diagrams, flowcharts, or examples can be implemented,individually and/or collectively, by a wide range of hardware, software,firmware, or virtually any combination thereof.

The herein described subject matter sometimes illustrates differentcomponents contained within, or connected with, different othercomponents. It is to be understood that such depicted architectures aremerely exemplary, and that in fact many other architectures can beimplemented which achieve the same functionality. In a conceptual sense,any arrangement of components to achieve the same functionality iseffectively “associated” such that the desired functionality isachieved. Hence, any two components herein combined to achieve aparticular functionality can be seen as “associated with” each othersuch that the desired functionality is achieved, irrespective ofarchitectures or intermedial components. Likewise, any two components soassociated can also be viewed as being “operably connected”, or“operably coupled”, to each other to achieve the desired functionality,and any two components capable of being so associated can also be viewedas being “operably couplable”, to each other to achieve the desiredfunctionality. Specific examples of operably couplable include but arenot limited to physically mateable and/or physically interactingcomponents and/or wirelessly interactable and/or wirelessly interactingcomponents and/or logically interacting and/or logically interactablecomponents.

With respect to the use of substantially any plural and/or singularterms herein, those having skill in the art can translate from theplural to the singular and/or from the singular to the plural as isappropriate to the context and/or application. The varioussingular/plural permutations may be expressly set forth herein for sakeof clarity.

It will be understood by those within the art that, in general, termsused herein, and especially in the appended claims (e.g., bodies of theappended claims) are generally intended as “open” terms (e.g., the term“including” should be interpreted as “including but not limited to,” theterm “having” should be interpreted as “having at least,” the term“includes” should be interpreted as “includes but is not limited to,”etc.). It will be further understood by those within the art that if aspecific number of an introduced claim recitation is intended, such anintent will be explicitly recited in the claim, and in the absence ofsuch recitation, no such intent is present. For example, as an aid tounderstanding, the following appended claims may contain usage of theintroductory phrases “at least one” and “one or more” to introduce claimrecitations. However, the use of such phrases should not be construed toimply that the introduction of a claim recitation by the indefinitearticles “a” or “an” limits any particular claim containing suchintroduced claim recitation to inventions containing only one suchrecitation, even when the same claim includes the introductory phrases“one or more” or “at least one” and indefinite articles such as “a” or“an” (e.g., “a” and/or “an” should typically be interpreted to mean “atleast one” or “one or more”); the same holds true for the use ofdefinite articles used to introduce claim recitations. In addition, evenif a specific number of an introduced claim recitation is explicitlyrecited, those skilled in the art will recognize that such recitationshould typically be interpreted to mean at least the recited number(e.g., the bare recitation of “two recitations,” without othermodifiers, typically means at least two recitations, or two or morerecitations). Furthermore, in those instances where a conventionanalogous to “at least one of A, B, and C, etc.” is used, in general,such a construction is intended in the sense one having skill in the artwould understand the convention (e.g., “a system having at least one ofA, B, and C” would include but not be limited to systems that have Aalone, B alone, C alone, A and B together, A and C together, B and Ctogether, and/or A, B, and C together, etc.). In those instances, wherea convention analogous to “at least one of A, B, or C, etc.” is used, ingeneral, such a construction is intended in the sense one having skillin the art would understand the convention (e.g., “a system having atleast one of A, B, or C” would include but not be limited to systemsthat have A alone, B alone, C alone, A and B together, A and C together,B and C together, and/or A, B, and C together, etc.). It will be furtherunderstood by those within the art that virtually any disjunctive wordand/or phrase presenting two or more alternative terms, whether in thedescription, claims, or drawings, should be understood to contemplatethe possibilities of including one of the terms, either of the terms, orboth terms. For example, the phrase “A or B” will be understood toinclude the possibilities of “A” or “B” or “A and B.”

While various embodiments have been disclosed herein, other aspects andembodiments will be apparent to those skilled in art. The various sportsand embodiments disclosed herein are for purposes of illustration andare not intended to be limiting, with the true scope and spirit beingindicated by the following claims.

What is claimed is:
 1. A computing device, comprising: a processor; anda non-transitory computer-readable storage medium coupled to theprocessor and having stored thereon computer executable instructions,that in response to execution by the processor, cause the processor toperform or control performance of operations that include: stream afirst media file to a media device, wherein the first media file isresident on the computing device; identify a request, received from themedia device, to stream a second media file, resident on the computingdevice, to the media device, wherein the request is received in responseto a determination, by the media device, that the first media file isunrenderable on the media device; and in response to the identificationof the request, stream the second media file to the media device,wherein the second media file is streamed to the media device based on atime code associated with the second media file, and wherein the secondmedia file remains resident on the computing device.
 2. The computingdevice of claim 1, wherein the first media file is unrenderable on themedia device when the first media file is corrupted.
 3. The computingdevice of claim 1, wherein the time code is indicative of an amount oftime that has elapsed from a first temporal point in the first mediafile to a second temporal point in the first media file, and wherein thetime code identifies a starting point in the second media file based onthe amount of time that has elapsed.
 4. The computing device of claim 1,wherein the time code identifies a starting point within the secondmedia file, and wherein the second media file is configured to begin tostream at the starting point identified by the time code.
 5. Thecomputing device of claim 4, wherein the starting point includes a firststarting point, and wherein the operations further include: identify aninput received from the media device, wherein the input includes anoverride of the time code and a second starting point, and wherein thesecond starting point is different from the first starting point; andstream the second media file to the media device, wherein the secondmedia file is configured to begin to stream to the media device at thesecond starting point instead of the first starting point, based on theoverride of the time code.
 6. The computing device of claim 4, whereinthe operations further include: modify the starting point based on anelapsed time of transmission of the second media file to the mediadevice.
 7. The computing device of claim 1, wherein at least one of thefirst media file and the second media file comprises one of a text file,a data file, an audio file, a video file, and an audiovisual file.
 8. Acomputing device, comprising: a processor; a receiver coupled to theprocessor and configured to receive a first media file from a sourcedevice, wherein the first media file is resident on the source device,wherein the processor is configured to perform or control performance ofat least one operation to determine that the first media file isunrenderable on the computing device; and a transmitter coupled to theprocessor and configured to, in response to the determination that thefirst media file is unrenderable on the computing device, send arequest, to the source device, to stream a second media file resident onthe source device to the computing device, wherein the receiver isfurther configured to, in response to the request, receive the secondmedia file from the source device, wherein the second media file isconfigured to be rendered on the computing device based on a time codeassociated with the second media file, and wherein the second media fileremains resident on the source device.
 9. The computing device of claim8, wherein the first media file is unrenderable on the computing devicewhen the first media file is corrupted.
 10. The computing device ofclaim 8, wherein the time code is indicative of an amount of time thathas elapsed from a first temporal point in the first media file to asecond temporal point in the first media file, and wherein the time codeidentifies a starting point in the second media file based on the amountof time that has elapsed.
 11. The computing device of claim 8, whereinthe time code identifies a starting point within the second media file,and wherein the second media file is rendered at the starting pointidentified by the time code.
 12. The computing device of claim 11wherein the starting point includes a first starting point, and whereinthe processor is further configured to perform or control performance ofoperations that include: provide an input that includes an override ofthe time code and a second starting point, wherein the second startingpoint is different from the first starting point; and render the secondmedia file on the media device, wherein the second media file isrendered on the media device at the second starting point instead of thefirst starting point, based on the override of the time code.
 13. Thecomputing device of claim 8, wherein the computing device comprises oneof a home media server, a digital video server, a video receiver, acomputer, a cellular telephone, a smart telephone, a personal digitalassistant, a digital music player, a digital video player, a portablevideo player, a wireless handheld device, a mobile communication device,a vehicle navigation system, a vehicle media system, a laptop personalcomputer, a notebook, and a mobile computing device.
 14. A method formedia communication, the method comprising: transmitting, by a sourcedevice, a first media file to a media device, wherein the first mediafile is resident on the source device; receiving, by the source devicefrom the media device, a request for transmission of a second media fileresident on the source device to the media device, wherein the requestis received in response to a determination, by the media device, thatthe first media file is unrenderable on the media device; and inresponse to the received request, transmitting, by the source device,the second media file to the media device, wherein the second media fileis rendered on the media device based on a time code associated with thesecond media file, and wherein the second media file remains resident onthe source device.
 15. The method of claim 14, wherein the first mediafile is unrenderable on the media device when the first media file iscorrupted.
 16. The method of claim 14, further comprising: determiningan amount of time that has elapsed from a first temporal point in thefirst media file to a second temporal point in the first media file; anddetermining the time code based on the amount of time that has elapsed.17. The method of claim 14, further comprising: determining the timecode that identifies a starting point in the second media file; andrendering the second media file on the media device at the startingpoint identified by the time code.
 18. The method of claim 17, whereinthe starting point includes a first starting point, and wherein themethod further comprises: receiving an input from the media device,wherein the input includes an override of the time code and a secondstarting point, and wherein the second starting point is different fromthe first starting point; and transmitting the second media file to themedia device, wherein the second media file is rendered on the mediadevice at the second starting point instead of the first starting point,based on the override of the time code.
 19. The method of claim 17,further comprising modifying the starting point based on an elapsed timeof transmission of the second media file to the media device.
 20. Themethod of claim 14, wherein at least one of the first media file and thesecond media file comprises one of a text file, a data file, an audiofile, a video file, and an audiovisual file.
 21. A computing device,comprising: a processor; a receiver coupled to the processor andconfigured to, in response to a determination by a media device that afirst media file is unrenderable on the media device, receive a requestfrom the media device for transmission of a second media file to themedia device, wherein the second media file is identified by a mediacode, wherein the processor is configured to perform or controlperformance of operations that include: in response to the receipt ofthe request, perform a search for the second media file in a media storeof the media device; locate the second media file in the media storebased on the performed search; acquire the second media file from themedia store based on a successful completion of a payment transactionassociated with the second media file; and configure the acquired secondmedia file to enable the second media file to be rendered on the mediadevice, wherein the acquired second media file is configured based on atime code associated with the second media file; and a transmittercoupled to the processor and configured to transmit the configuredsecond media file to the media device.
 22. The computing device of claim21, wherein the first media file is unrenderable on the media devicewhen the first media file is corrupted.
 23. The computing device ofclaim 21, wherein the time code identifies a starting point within theacquired second media file, and wherein the processor is furtherconfigured to perform or control performance of at least one operationthat includes: configure the acquired second media file to be renderedon the media device at the starting point identified by the time code.24. The computing device of claim 21, wherein to configure the acquiredsecond media file, the processor is further configured to perform orcontrol performance of at least one operation that includes: convert theacquired second media file to at least one of a format, a file size, andan encryption format capable to be rendered on the media device.